SESAME V2 public key and authorisation extensions to Kerberos

realms (or between realm hierarchies) limits the extent to which Kerberos can be realistically used to secure communications between different organisations, or even to scale across large enterprises which may have divisions operating loosely coordinated security policies, and which find difficulty managing the effort of maintaining shared secrets with each remote realm or group of realms that they need to keep in contact with. There are increasing requirements for availability of practical solutions to the problem of providing secure single sign-on for users to applications anywhere on the network, but with affordable security management. Kerberos1 has been proven to be an effective solution to this problem for a local network, or within closely linked groups of users, but Kerberos is constrained by its current limitations of supporting purely symmetric key distribution, and an identity-based authorisation model. This paper describes how the SESAME2 Project has integrated asymmetric key distribution, and authorisation support to extend Kerberos to provide significant scalability and manageability improvements. The effort involved in installation and management of the keys for users and hosts within Kerberos realms is containable. However, as creation of a new application service requires registration as a Kerberos principal, the overheads associated with setting up and maintaining a key for each target application tend to lead to many target Kerberized applications running as the same Kerberos principal, often as root user id. 1: Introduction In addition, while extensions can be defined, the Kerberos standard supports authentication not access control. Therefore each application must determine authorisation solely on the basis of the user's identity carried in the service ticket hence each application must be configured with the identity of all possible users. This leads to management overheads of tracking down and modifying such access control entries if a user changes their job responsibilities, or leaves the company. This section reaffirms recognised strengths of Kerberos [1, 2], and discusses some of its limitations as a basis for cost-effectively protecting distributed applications on a large-scale. It is then outlined where SESAME V23 has extended Kerberos, and the remainder of the paper describes the extensions in more depth. 1.1: Strengths and Management Overheads of the Kerberos Authentication system The deployment and use of Kerberos in many live user environments has proven in practice its ability to provide the foundation for authentication and building secure distributed applications within departmental units, or cooperating work-groups. 1.2: SESAME Extensions to Kerberos SESAME builds from Kerberos, so that it can complement its strengths, but focus on addressing its limitations, as discussed above. The primary extension provided by SESAME is to support asymmetric inter-realm key distribution to make scalable secure interworking practical between remote realms. Additionally, within each host, a trusted service authenticates clients, and thereby reduces the overheads of maintaining keys for each application, except where necessary for them to act as principals in their own right. However, the use of symmetric cryptography, and hence the need to set up and maintain shared secrets between 1 Kerberos is a trademark of MIT 2 SESAME Secure European System for Applications in a Multi-vendor Environment is a project under the auspices of the European Commision (EC) RACE programme. SESAME also defines a scheme for securely propagating principals' privileges, including roles and groups, from clients to servers in order to reduce access control management overheads at end-systems, but provides policy control safeguards to limit which applications can be accessed, and which, if any, can act as delegates. 3 SESAME V2 SESAME Technology Version Two includes the SESAME-enhanced version of Kerberos, and is entering user beta tests at time of writing. 2: Structure A facility to grant Privilege Attribute Certificates (PAC) to authenticated users This paper initially gives a black box view of the SESAME V2 implementation by first presenting the externally visible run-time and administrative facilities, and then by outlining the underlying system security objectives so that it is clear what resources are protected, and against what threats. Secure transfer and controlled delegation of PACs from users to their applications (i.e. : the push model of access control) Separate audit identity (for accountability) and access identity (for access control) A white box view of SESAME V2 is given next by describing the internal SESAME V2 architectural components, their interfaces, the inter-component trust model, and the management information associated with each component. Elimination of the need to manage keys for applications which don't act as principals in their own right Provision of Base GSS-API [10] to application developers, with extensions for requesting and querying privileges [11]. The remainder of the paper focuses on the intercomponent protocol, with particular emphasis on how SESAME V2 relates to and extends [2]. Initially an overview is given of the scheme for protection of nondelegatable and delegatable Privilege Attribute Certificates (PACs). It is then shown how SESAME V2 secures applications within realms by presenting the protocol used to obtain a PAC and form a security context, and highlighting the caching which is made possible through use of the PAC Validation Facility (PVF). Next it is described how a PAC may be delegated, if policy so permits. Finally, it is shown how key distribution and security of PAC transfer is implemented using asymmetric techniques between realms. Certification and revocation [17] of public keys of Privilege Attribute Services and KDSs. 3.2: Non-Functional Qualities Exploitation of caching of keying information, and public key technology, to minimise need for frequent contact with security servers Limited use of encryption minimally for keys and related security control information Support for different strengths of algorithm for user data integrity, & (optional) user data confidentiality Replacable cryptographic algorithms After a discussion of how SESAME V2 compares with other related work in the distributed security field, the paper concludes with an overview of the emerging SESAME V3, and a brief summary of the main points made in the paper. Exploitation of public key technology for increasing scalability, but no required support for asymmetric algorithms in users' workstations Facility for the user data protection mechanism (i.e. cryptographic algorithm and key length) to be specified by the context initiator 3: Run-time and Administrative Facilities To provide a context and motivation for the design, this section presents a summary of the current facilities in SESAME V2 both functional and non-functional, together with some explicit non-goals. See also [3]. [4], [5]. [6], [7], [8], and [9] for background and more detail on ECMA work on Security in Open Systems, and on the generic SESAME architecture which is profiled by the current SESAME V2 implementation The subsequent sections show how these facilities have been implemented as a result of extending Kerberos. 3.3: Non-Goals of SESAME V2 Non-goal off-line security server 3.1: Functionality While off-line security servers provide some advantages appropriate to certain environments (by simplifying replication and protection of private keys), SESAME V2 supports on-line security servers as a direct result of extending (rather than re-inventing) Kerberos. Use of on-line security servers are important in the SESAME architecture because of their intrinsic advantages in Authentication and single sign-on for principals Secure association management support services to enable peers to authenticate securely over open, untrusted networks using a hybrid symmetric / asymmetric key distribution scheme. Support for associating principals with roles and group affiliations business environments where controls on user system access are required. asymmetric principal authentication scheme is being developed as part of SESAME V3. 4: Security Objectives Particular benefits of on-line security servers are the ability to facilitate security policies which require constraints and monitoring on who can sign-on to a system even before any access to target applications are allowed. In addition on-line security servers permit signon controls based on a user's originating workstation, enable immediate revocation, and reduce requirements for public key cryptography. Systems are vulnerable to many different possible forms of attack on their resources. In order to enable a clear distinction between the attacks which are considered relevant, and those which are not, it needs to be understood, whether a possible security goal (for example, integrity or confidentiality) is required for each system resource. Hence, security objectives are summarised here, and essentially identify the protection requirements for the system critical resources (both external and internal). Comparison of off-line and on-line security servers is discussed in more detail in [9]. Non-goal use of ANSI X.9 Attribute Certificates or OSF DCE PACs Security Context Establishment Services are provided via the GSS-API to produce and verify security exchange information tokens so that authenticated communicating peers may establish security contexts across untrusted networks. The security context should provide peer-authentication (optionally mutual), and achieve a secure transfer of access rights from security context initiator to target application. ANSI X.9 is defining certificate management standards which include new asymmetrically protected attribute certificates (expressed using the mosr recent revision of the ASN.1 standard [16]). OSF has defined symmetrically protected PACs in DCE 1.0 which support groups, and its next release is expected to support other privileges and controls in the PACs (which are encoded using NDR). User Data Protection Services are provided to applications so that application data specified by the GSS-API user may be integrityprotected, or confidentiality-protected (subject to policy) when passed by the application on the connection between initiator and target application systems over which a security context has been established. A continuing authentication service must be provided so that the identities of the communicating peers remain constant for the duration of a security context. The SESAME V2 implementation used the PAC defined by the European Computer Manufacturers' Association (ECMA) [5] as its syntax provided the required functions, and enables use of the same abstract syntax and encoding mechanisms as used in Kerberos V5. Non-goal non-repudiation The support of non-repudiation (e.g.: to counter threats of an application server, or security server falsely claiming, or conversely, repudiating that a client had accessed it) is not an objective. Limited Requirements for Confidentiality For legal and performance reasons, use of confidentiality shall be minimised as part of the security mechanism itself. There is no requirement for encryption of PACs or other security protocol elements (other than keys, and confidential control information). However, user data may be confidentiality protected if policy permits this. Non-goal integration with specific public key directory infrastructure No support for a specific directory (OSI, or NIS, or extended DNS etc) or other means of managing and obtaining public keys for principals is mandated. In SESAME V2, local certificate management is supported, and, where appropriate, security server certificates and associated information are passed in-band as part of security context formation. Required Duration of Security Contexts For SESAME V2, short duration security contexts are required (i.e. able to resist attack by a knowledgable adversary with normal equipment for at least week). System Data Protection For multi-user system environments, the SESAME V2 implementation must protect internal credential and context information held locally, whether in persistent or transient storage, from being misused or being disclosed to an unauthorised entity. Non-goal enhanced principal authentication Support for alternatives to Kerberos password-based authentication which are not vulnerable to dictionary attacks is not an objective of SESAME V2, although an Protection Against Untrusted Workstations Public Key Management (PKM) manages public keys and certificates A user at an untrusted single user workstation must not be able to accidentally or maliciously obtain unauthorised access to any other principal's credentials or data. Audit enables audits of security relevant events by applications (audits with the audit id from the PAC) 5: SESAME V2 Components 5.2: SESAME Extended Kerberos Components 5.1 SESAME components The client Kerberos code is integrated into the User Sponsor and SACM. The User Sponsor is implemented as a set of user interface utilities, whereas the SACM code is linked in with application clients via GSS-API. The application server Kerberos code is separated between the PVF for ticket verification, and SACM for per-message protection using "dialogue keys" derived from the session key. Similarly to the client, the server SACM code is linked in with each application. Privilege Attribute Service (PAS) grants PACs according to policy for principals to access authenticated applications, and issues KDS Tickets by adding per-session identifiers into Ticket Granting Tickets (TGTs) linking them with the PAC(s). PAC Validation Facility (PVF) a trusted per-host daemon used to isolate functionality of verifying tickets and PACs, and used to authenticate host applications to clients. Hence no application shares a long term key with the KDS for the purposes of ticket verification (security context acceptance) although an application may optionally have a key if it needs to act as a principal (security context initiation). The rationale for this separation is both to reduce management overheads, and to reduce the amount of code which needs have access to long term keys. Secure Association Context Manager (SACM) implements SESAME mechanism for forming security contexts within and between realms, and protects credential and keying information from misuse. Supports GSS-API interface to applications. User sponsor (US) provides the user interface (CLI or GUI) to authentication (seslogin), selecting or changing roles (chattr), and logging out (seslogout) The SESAME Key Distribution Service (KDS) uses Kerberos authentication functions (TGT acquisition) unchanged. Similarly, intra-realm ticket acquisiton is basically unchanged, but some additional data is added to include the list of applications served by the PVF. However, Kerberos V5 inter-realm authentication and key distribution is augmented with an asymmetric scheme which permits dynamic establishment of a shared key with the remote realm (discussed later in the paper). Authentication and Privilege Attribute (APA) Client interfaces to authentication. The APA Client isolates the authentication mechanism from the User Sponsor. Cryptographic Support Facility (CSF) isolates code from algorithm choice (default is DES, MD5, and RSA in SESAME V2) Certification Authority (CA) certifies security servers' public keys, and issues CRLs